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1.  INTRODUCTION 


The  VIPER  (1,  2)  Microprocessor  vu  invented  st  RSRE  to  sstisfy  the  need  for 
s  highly  trusted  32-bit  computer  which  can  be  used  in  safety  critical 
applications.  The  need  for  such  a  chip,  has  arisen  in  areas  such  as  the  arming 
and  fusing  of  weapons,  "fly  by  wire”  control  systems  in  high  performance 
military  and  civil  aircraft  and  in  the  instrumentation  of  nuclear  reactors.  The 
majority  of  widely  available  microprocessors  are  regarded  as  unsatisfactory 
for  safety  critical  applications  because  they  have  instruction  sets  that  are 
too  rich  and  that  lead  to  programmer  confusion  and  problems  with  formal 
verification  of  the  software  to  run  on  that.  Also,  they  are  documented  in 
natural  language  (with  its  inherent  ambiguities)  and  their  designs  are 
validated  by  simulation  (a  process  that  cannot  give  a  1002  guarantee  of 
correctness).  The  aim  of  the  VIPER  project  has  therefore  been  to  design  a 
processor  architecture  well  matched  to  critical  applications,  to  define  it 
rigorously  (this  document)  and  to  attempt  to  prove  by  mathematical  means  (5,6) 
the  correctness  of  circuits  designed  to  meet  this  specification  (in  addition  to 
their  conventional  validation  by  simulation). 

This  Report  specifies  the  VIPER  architecture  in  two  ways : - 

a)  Informally,  using  a  conventional  description  of  the  instruction  set 

b)  Formally,  using  the  notation  of  the  HOL  system  (Higher  Order  Logic), (3) 

developed  at  the  University  of  Cambridge 

The  purpose  of  this  Report  is  to  provide  an  unambiguous  description  of  the 
functional  behaviour  of  VIPER.  This  is  usually  referred  to  as  the  top-level 
specification  and  corresponds  to  the  programmer's  view  of  the  processor.  This 
viev  excludes  such  considerations  as  electrical  properties  and  detailed 
timings,  which  can  be  found  in  reference  2.  A  number  of  VLSI  technologies  have 
been  used  to  realise  machines  vhich  respect  the  specification  given  in  this 
document,  using  in  the  region  of  4000-5000  logic  array  cells  (vhich  illustrates 
tie  inherent  simplicity  of  the  architecture). 

This  report  replaces  the  earlier  RSRE  report  85013  (9)  vhich  provided  the 
formal  description  of  VIPER  in  the  LCF-LSM  language  (4).  This  was  the  precursor 
of  HOL,  but  as  the  proofs  of  correctness  to  shov  the  validity  of  VIPER'S  major 
state  and  block  level  lmplemen tat ions  (5,6)  were  done  in  HOL,  this  nev 
specification  should  be  regarded  as  the  definitive  description.  There  are  only 
minor  syntactic  differences  between  LCF-LSM  and  the  sub-set  of  the  HOL  logic 
used  here,  so  this  description  and  the  previous  report  are  almost  identical. 
However,  there  is  one  substantive  change  in  the  function  NEXT.  This  will  be 
described  in  the  appropriate  section.  This  HOL  description  was  derived  from  the 
earlier  LCP-LSM  description  by  Dr  Avra  Cohn  of  Cambridge  University. 
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2.  INFORMAL  DESCRIPTION  OF  ARCHITECTURE 


The  rationale  for  the  VIPER  architecture  is  given  in  reference  1.  As  shovn 
in  Fig  1,  the  conceptual  machine  has  an  accumulator.  A,  of  32-bits,  two  index 
registers,  X  and  T  also  of  32-bits  and  a  register  for  the  prograe  counter  P,  of 
width  20-bits.  VIPER'S  sain  memory  is  1  Mega-vord.  This  is  used  as  the  source 
of  all  ins true ti one  and  the  source  and  destination  of  most  data  operations. 
However  VIPER  has  a  separa'  .  1  Mega-vord  memory  space  available  for  peripheral 
devices,  which  is  only  accessed  by  the  INPUT  and  OUTPUT  instructions.  In  both 
cases  the  data  path  is  32-bits  vide.  Selection  between  the  domain  of  the  main 
memory  and  the  input/output  space  is  achieved  by  a  1-bit  signal.  Proa  the 
point  of  view  of  this  specification,  all  of  the  main  memory  and  the 
input/output  space  can  be  viewed  as  Random  Access  Memory  (RAM)  addressed  by 
21-bits  in  total,  i.e.  a  memory/ io  control  bit  concatenated  vith  a  20-bit 
address  generated  by  the  rest  of  the  aachine. 

In  addition  to  the  above  registers,  the  architecture  has  a  single  1-bit  flag 
register,  B,  which  holds  the  results  of  comparison  instructions  and  carry  bits 
from  arithmetic  or  shift  operations.  The  final  key  feature  is  a  single  Boolean, 
STOP,  which  becomes  true  if  any  logical  error  occurs  in  the  execution  of  a 
program  in  VIPER,  such  as  arithmetic  overflov  or  generation  of  an  offset 
address  larger  than  20-bits.  In  such  circumstances  the  machine  must  halt.  If 
the  real  time  application  requires  continued  operation,  this  must  be  achieved 
by  external  means,  such  as  redundant  processing  capability  or  by  switching  to 
an  alternative  program. 

Prom  the  tvo  paragraphs  above  it  will  be  seen  that  a  'state'  in  which  the 
machine  rests  momentarily  between  instructions  can  be  written  down  as  the 
vector 


(RAM,  P,  A,  X,  T,  B,  STOP) 

vhere  P,  A,  X,  T,  B  imply  the  current  contents  of  these  registers  and  STOP  the 
current  setting  of  the  stop  condition.  The  element  RAM  implies  the  current 
contents  of  both  address  spaces.  The  essence  of  the  specification  given  in  this 
document  is  to  define  rigorously  all  transitions  from  one  such  state  to  another 
for  all  possible  instructions  stored  in  the  main  memory. 

Instructions  are  stored  as  groups  of  fields  occupying  the  highest  12-bits  of 
each  word.  The  remaining  20-bits  represent  either  an  address  or  a  constant. 

Throughout  this  specification  the  bits  of  a  word  are  numbered  from  0  at  the 
least  significant  end.  For  the  purposes  of  definition  the  aachine  is  assumed 
to  have  an  Arithmetic  and  Logic  Unit  (ALU)  with  two  32-bit  inputs,  denoted  by 
convention  as  R  and  M,  but  these  values  are  not  directly  accessible  to  the  user 
and  are  not  part  of  the  primary  state  of  the  VIPER  aachine. 

It  should  be  noted  that  events  such  as  reset  which  are  caused  by  the 
'environment'  in  which  VIPER  is  operating  are  regarded  as  being  outside  the 
programmer's  view  of  normal  operation,  and  so  are  not  formally  defined  in  this 
document.  Informally,  a  reset  may  occur  at  any  time  and  causes  all  the 
registers  (A,  X,  I,  P,  B  and  STOP)  to  be  cleared.  The  other  similar  event  that 
may  occur  is  a  forced  error,  when  for  example  hardware  external  to  the 
processor  detects  a  parity  fault  in  the  memory  and  forces  the  processor  into 
the  stopped  state.  The  effect  of  a  forced  error  is  to  set  the  STOP  flag,  thus 
preventing  further  instructions  being  executed,  until  cleared  by  reset. 
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The  fields  formed  from  the  32-bits  of  each  VIPER  instruction  can  be  defined  as 
shown  in  Table  1:- 


TABLB  1.  INSTRUCTION  DECODING 


I  Field  |~I3ent-  |  fli'gh 

|  |  ifier  |  Bit 

|  Low  |  Length  |  Defining  | 

Bit  |  Bits  |  | 

Register  select 

rsf 

31 

30 

2 

READ:  source  of 

R  input  to  ALU 
WRITE:  register 
to  be  written 

Meaory  select 

msf 

29 

28 

2 

RBAD:  source  of 

H  input  to  ALU 
WRITE:  memory 
or  io  address 
SHIFT:  shift  op 

(Destination  select |  dsf  |  27  |  25  |  3  |  Destination  of  | 

1  1  1  1  1  1  result  | 

| Comparison  select  |  csf  |  24  |  24  |  1  |  1-compare  | 

|  1  1  1  1  1  O-arithmetic  op  | 

|  Function  select  |  fsf  |  23  |  20  |  4  |  Coaparison  | 

j  j  III  j  or  ALU  function  j 

|  Address  |  addr  |  19  |  0  |  20  |  Address  or  20  | 

j  j  j  j  j  j  bit  constant  j 

The  next  level  of  decoding  is  illustrated  in  the  following  tables,  which 
indicate  the  coding  of  each  field.  The  R  input  of  the  ALU  or  the  register  to  be 
written  into  RAH  is  selected  by  the  Register  Select  Field  as  shown  in  Table  2:- 


TABLE  2.  REGISTER  SELECT  FIELD 


|Value  of  rsf  |  R  input  to  ALU  or 

1 

1 

|  value  to  be  written  to  a« 

smory  | 

1  o 

1  A 

I 

|  1 

1  * 

| 

1  2 

1  T 

I 

1  3 

1 

|  P,  padded  to  32-bits 
j  with  leading  seros 

1 

1 

3 


The  memory  select  field  has  several  roles,  depending  on  the  values  of  the 

other  fields  of  the  instruction,  these  are  illustrated  in  Table  3:~ 

Case  It  (csf  -  0)  AMD  (dsf  >  5)  is  a  WRITE  operation,  msf  indicates  the  address 

Case  2:  (csf  -  1)  OR  ((dsf  <-  5)  AND  (fsf  /-  12))  is  a  comparison  or 

arithmetic  operation,  vith  either  an  operand  being  read  from  memory  or 
the  20-bit  tail  of  the  instruction  being  allocated  as  a  constant  to  the 
M  input  of  the  ALU 

Case  3:  (csf  -  0)  AND  ((dsf  <«  5)  AND  (fsf  -  12))  is  a  shift  operation,  vith 
msf  defining  which  of  the  four  possible  shift  instructions  is  to  be 
performed 


TABLE  3.  MEMORY  SELECT  FIELD 


11 

MffWP  MU'I  ffTl1)' M 

|  {csf  -  1)  OR 

"(Eif  -  0)  AND — 

H 

|  ((dsf  <-  5)  AND 

(dsf  <-  5)  AND 

II 

|  (fsf  /-  12)) 

(fsf  -  12) 

1  o 

1 

1 

Illegal 
stop  -  TRUE 

Assign  constant 
Padded  to  32 
bits  to  H 

j  1  |  Write  source 
j  j  (rsf)  to  addr 
|  1 

Read  from  addr 
and  assign 
result  to  M 

1 

2 

IF  (addr  4  X)  |  IP  (addr  +  X)  j 

is  <*  20-bits  j  is  <-  20  bits  j 
vrite  to  this  j  read  from  this  j 
location  j  location  and  j 

ELSE  stop  j  assign  result  | 

|  to  H,  ELSE  stop  | 

3 

IF  (addr  +  T) 
is  <-  20-bits 
vrite  to  this 
location 

ELSE  stop 

IF  (addr  +  T) 
is  <m  20  bits 
read  from  this 
location  and 
assign  result 
to  H,  ELSE  stop 

No  WRITE  or 
READ.  Defines 
one  of  four 
shift  inst¬ 
ructions,  as 
listed  in 
Table  6 


As  indicated  above,  the  destination  select  field  controls  the  read/vrite 
operations,  subject  to  conditionals  such  as  indexed  addresses  being  vithin  the 
20-bit  range  of  the  machine.  The  definition  of  the  coding  of  dsf  is  given  in 
Tables  AA  &  4B,  in  which  the  values  of  the  predicates  are  indicated  by  1,  0  or 
X  (for  either  value).  Bach  column  in  such  a  table  defines  a  combination  of 
conditions  and  the  actions  which  must  be  performed  if  these  circumstances  are 
encountered  in  the  execution  of  a  program.  The  'actions'  in  this  specification 
of  WIPER  are  assignments  to  the  elements  of  the  state  vector  (RAH,  A,  X,  T,  p, 
B,  STOP). 
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Notes  on  each  column,  vith  (RES,  BVAL,  SVAL)  delivered  by  ALU: - 

1.  Processor  has  halted 

2.  Invalid  address  or  illegal  operation,  vhlch  aust  cause  processor  to  halt. 

3.  Comparison  functions,  see  Table  5  for  vhlch  function  is  required. 

4.  Vrite  to  memory  (dsf-7)  or  io  (dsf-6) 

*  regval  is  the  contents  of  the  register  defined  by  rsf  vritten  into  the  RAN 

5.  No  operation,  (dsf«5)  AND  B 

6.  Conditional  CALL, 

*  P  loaded  vith  bo t ton  20-bits  of  RES  and  7  loaded  vith  P+1  padded  to  32-bits 

7.  Conditional  GOTO, 

*  P  loaded  vith  bo t toe  20-bits  of  RES 
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TABLE  4B.  DESTINATION  SELECT  FIELD  LOGIC 


Coluan  nuaber  | 


|  STOP 


9  |  10  |  11  |  12  | 


0  |  0  |  0  1  0  | 


13  |  14  |  15  | 


Invalid  address  or 
illegal  operation, 
excluding  illegal 
calls  (see  col  16) 


|  coapare  (csf  ■  1) 


|  value  of  dsf 


call  ( fsf  -  1) 


4 1 

.  —  —  A— - 

4  1 

4  I 

3  1 

3  1 

2  I 

—  « 

0  1 

TT 

if 

’  x  1 
,  _  _  . 

X  f 

T 

X  1 

x  1 

■  1  ■  1 

1  1 

o  i 

T 

1  1 

o  r 

0  1 

CHANGES  VALUE  OF:- 

RAM  (aeaory  +  i/o) 

A 

X 

T 

P 

B 

STOP 


I  I 

|  -  P+1  |  -  P+1 

j  P+1  RES  j  RES  RES 

I  -  BVAL  |BVAL  BVAL 

|  -  SVAL  jSVAL  SVAL 


0  I  <3  | 


X  |  X  | 


I  I  I 

-  |  -  |  RES  |  - 

-  j  RES  j  -  j  - 

RES  j  -  j  -  j  P+1 

RES  P+1  j  P+1  |  P+1  |  P+1 

BVAL  BVAL  |BVAL  |BVAL  j  - 
SVAL  SVAL  j  SVAL  j  SVAL  |TRUE 


Notes  on  coluans. 

8.  No  operation,  (dsf -4)  AND  (NOT  B) 

9.  Conditional  CALL 

*  P  loaded  vith  bottoa  20-bits  of  RES,  T  loaded  vith  P+1  padded  to  32-bits 
1).  Conditional  GOTO:  *  P  loaded  vith  bottoa  20-bits  of  RES 

11.  Unconditional  CALL 

*  P  loaded  vith  bottoa  20-bits  of  RES,  T  loaded  vith  P+1  padded  to  32-bits 

12.  Unconditional  GOTO:  *  P  loaded  vith  bottoa  20-bits  of  RES 
13.. 15  Assignaents  to  T,  X  or  A 

16.  Illegal  CALL  instructions 


TABLE  5.  COMPARISON  FUNCTIONS 


coaparator 


R  <  M 
R  >-  M 
R  -  M 
R  /-  M 
R  <-  M 
R  >  M 
unsigned  R  <  M 
unsigned  R  >«  M 


|  As  above,  but  vith  the  | 
j  the  result  Wed  vith  B  j 
|  eg:  8  ->  (R  <  M)  OR  B  | 


The  description  of  the  arithmetic  and  logic  functions  of  the  ALU  calls  for 
two  further  definitions  to  describe  the  error  conditions:- 

pvrite  a  Boolean  which  is  TRUE  if  the  destination  of  the  result  of  the 

operation  is  the  P  register  i.e.  value  of  dsf  -  3,  4  or  5.  Many 
of  the  ALU  operations  cannot  be  used  for  manipulating  the  program 
counter,  since  potentially  dangerous  effects  could  be  produced. 

Bence  pvrite  is  the  error  condition  for  "barred  on  P  register" 

(note  that  the  CALL  instruction  can  only  be  used  vith  destination  P). 

INVALID  An  operator  applied  to  the  32-bit  result  of  an  ALU  operation  vhich 
delivers  TRUE  if  this  value  has  any  one  of  the  top  12-bits  set 
i.e.  represents  an  impossible  address  or  value  of  the  program  counter 

The  following  tables  also  contain  the  values  'carry',  'borrov'  and 
'overflow',  vhich  are  defined  later. 


TABLE  6A.  ALU  FUNCTIONS  0-11 


TABLE  6B.  ALU  FUNCTIONS  12  -  15 


nsr- 

1 

| 

msf 

r 

function 

T 

i 

output 

"T 

1 

1 

1 

1 

RES 

1 

BVAL 

1 

SVAL 

1 

12 

1 

1 

0 

1 

1 

SHIFT  RIGHT 
copy  sign  bit 

jR31.R31..Rlj 

1  1 

B 

i 

i 

pvrite 

I 

1 

12 

1 

1 

1 

1 

1 

SHIFT  RIGHT 
through  B 

1 

1 

B.R31..R1 

1 

1 

§ 

i 

i 

pvrite 

1 

12 

1 

2 

SHIFT  LEFT 
stop  on  overflov 

1 

1 

R  +  R 

1 

1 

B 

i 

i 

pvrite  OR 
overflov 

1 

12 

i 

i 

3 

SHIFT  LEFT 
through  B 

i 

i 

R30..R0.B 

1 

1 

R31 

i 

i 

pvrite 

1 

1 

13 

i 

any 

Illegal 

i 

R 

1 

B 

i 

TRUE 

14 

i 

any 

Illegal 

i 

R 

1 

B 

i 

TRUE 

15 

i 

any 

Illegal 

i 

R 

1 

B 

i 

TRUE 

1 

Note:- 

In  the  notation  used  for  the  shifts,  Ra..Rn  denotes  a  slice  of  the  bits  in 
the  R  input  to  the  ALU  and  .  (full  stop)  denotes  concatenation. 


3.  FORMAL  SPECIFICATION  IN  HOL 

The  HOL  system  has  been  devised  by  the  Computing  Laboratory  of  the 
University  of  Cambridge,  using  the  interactive  progressing  language  ML  (Meta 
Language),  and  is  a  development  of  LCF-LSM.  The  origins  of  this  vork  are 
described  in  a  book  by  Gordon,  Milner  and  Wadsvorth  (7). 

In  this  Section  VIPER  is  specified  in  the  style  proposed  by  Gordon  (8),  using 
the  primitive  functions  defined  in  the  present  Cambridge  HOL  system.  Annex  A 
gives  a  very  brief  introduction  to  the  HOL  constructs  used  and  the  reader 
should  turn  to  those  pages  next  to  gain  an  initial  understanding. 

The  formal  specification  is  presented  on  the  folloving  pairs  of  pages,  each 
page  of  HOL  text  having  a  facing  page  of  commentary.  Inevitably  any  such 
specification  needs  a  number  of  auxiliary  functions,  to  enable  the  primary 
axiom  for  the  next  state  of  the  machine  to  be  defined  in  a  concise  manner. 
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The  specification  of  VIPER  begins  vith  tvo  declarations,  kO  create  types  for 
vords  of  fixed  nuabers  of  bits  and  to  create  a  hypothetical  address  space:- 

declarevord  widths! 1 ; 2; 3;4; 20; 21; 32; 33; 34] 
declareaemories [(21,32)] 

This  introduces  the  types  vordl,  vord2,  . ...vord34  and  the  standard  functions 
for  converting  these  types  to  positive  integers  (of  type  nua)  and  to  lists  of 
booleans:- 


VAL1,  VAL2,  VAL3 
V0RD1,  W0RD2,  V0RD3 
BITS1,  BITS2,  BITS3 
N0T1,  N0T2,  N0T3 


VAL34  vordn  ->  nun 

W0RD34  nua  ->  vordn 

BITS34  vordn  ->  boollist 

HOT 34  vordn  ->  vordn 


Writing  to  and  reading  froa  the  address  space  created  by  dedare_aeaories  is 
achieved  using  the  pair  of  functions 

ST0RB21 :  vord21  ->  vord32  ->  aea21  32  ->  aea21  32 
FETCH21:  aea21_32  ->  vord21  ->  vord32 

The  first  functions  VALUE,  CARRY,  07L0,  BVAL  and  SVAL  exist  solely  to  extract 
a  single  field  froa  a  structured  value. 


A  nuaber  of  conversions  betveen  vords  of  differing  lengths  are  required  and 
this  is  the  role  of  the  three  functions  TRIH32T020,  TRIM34T032  and  PAD20T032. 
The  tria  functions  aake  use  of  the  concept  of  lists  and  HOL  functions  such  as 
SBG,  EL,  V  and  TL  (see  Annex  A).  As  defined,  triaaing  is  'blind'  in  the  sense 
that  no  checks  are  perforaed  to  see  if  significant  bits  are  lost  in  the 
triaaing. 


SIGNEXT  performs  sign  extension,  ie  increases  the  length  oi  a  vord  by 
duplicating  the  aost  significant  bit.  Much  use  of  this  vill  be  Bade  in  the  later 
definition  of  arithaetic  operations. 

RIGHT  and  LEFT  shift  a  vord  V  in  the  appropriate  direction,  losing  the 
right/left  aost  bit  and  adding  B  as  the  left/right  aost  bit. 

RIGHT  ARITH  provides  a  divide  by  tvo  operation  for  a  2's  complement  value. 

That  is,  the  value  is  shifted  one  place  right  vith  the  aost  significant  bit 
being  duplicated. 
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dedare_word  widths[l;2;3;4;20;21;32;33;34] 
declare  aeaoriesf (21 .32)] 


VALUE:  vord32£bool£bool  ->  vord32 
-  VALUE  (resdt, carry, overflow)  -  result 


CARET:  vord32£bool£bool  ->  bool 
-  CARRY  (result, carry, over flow)  -  carry 


OFLO:  vord32£bool£bool  ->  bool 
-  OFLO  (result, carry, overflow)  -  overflow 


BVAL:  word32£bool£bool  ->  bool 
-  BVAL  (result,  b,  abort)  «  b 


SVAL:  word32£bool£bool  ->  bool 
-  SVAL  (result,  b,  abort)  *  abort 


TRIM32T020:  word32  ->  word20 
-  TRIM32T020  w  -  VORD20(V(SEG  (0,19)  (BITS3?  w))) 


TRIM34T032 :  word34  ->  word32 
-  TRIM34T032  w  -  V0RD32(V(TL(TL(B1TS34  w)))) 


PAD20T032 :  word20  ->  word32 
-  PAD20T032  w  -  VORD32(VAL20  w) 


SIGNEXT:  word32  ->  word33 
-  SIGNEXT  v  - 

(let  bitlist  -  BITS32  w  in  WORD33(V(CONS(EL  31  bitlist)  bitlist))) 


RIGHT:  bool£word32  ->  word32 

-  RIGHT  (b,r)  -  V0RD32(V(C0NS  b  (SBG  (1,31)  (BITS32  r)))) 


LEFT:  word32£bool  ->  word32 
-  LEFT  (r,b)  -  (let  twice  .  V(TL(BITS32  r))  in 

(b  ->  WORD32( twice  +  twice)  +  1  |  V0RD32(twice  +  twice)) 


RIGHTARITH:  word32  ->  word32 
-  RIGHTARITH  r  -  (let  sign  -  EL  31  (BITS32  r)  in 

VORD32 ( V( CONS  sign  (SBG  (1,31)  (BITS32  r))))) 
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NEG  provides  a  negate  function  for  a  33-bit  2's  coapleaent  value.  It  uses 
the  usual  invert  and  add  1  algor it ha.  Mote  that  0  is  treated  as  a  special  case. 
If  this  were  not  reaoved  by  the  initial  test,  0  inverted  and  increaented  vould 
deliver  a  34-bit  result,  but  the  use  of  NEG  in  SUB32  and  COMPARE  is  such  that 
only  a  33-bit  value  is  required. 

ADD32  and  SUB32  are  the  addition  and  subtraction  operations  for  32 -bit 
values.  Both  deliver  triples,  a  32-bit  result,  a  carry  (or  borrow)  value  and  an 
overflov  condition.  The  32-bit  result  is  the  bottoa  32-bits  of  the  result  of 
adding/subtracting  the  two  operands  regardless  of  whether  they  are  2's 
coapleaent  or  unsigned  values.  The  carry  (or  borrow  for  subtraction)  value  is 
used  during  unsigned  operations  only,  whilst  the  overflow  value  is  only 
significant  during  2's  coapleaent  arithaetic.  An  inforaal  definition  of 
overflow  is  that  it  is  true  if  and  only  if  the  sub  (or  difference)  of  the  two 
operands  cannot  be  represented  by  a  32-bit  2's  coapleaent  value.  Siailarly, 
carry  or  borrow  are  defined  to  be  true  if  the  sub  (or  difference)  of  the  two 
operands  cannot  be  represented  by  a  32-bit  unsigned  value.  The  relationship 
between  these  inforaal  definitions  of  overflow  and  carry  and  their  foraal  BOL 
descriptions  is  investigated  in  Annex  B. 

Given  a  definition  of  ADD32,  the  function  to  increaent  the  prograa  counter 
P,  INCP32  is  as  shovn  opposite.  A  32-bit  value  is  delivered  to  cope  with  the 
situation  when  the  last  instruction  was  fetched  froa  the  top  word  in  aeaory, 
leading  to  P  overflowing  into  the  21st  bit.  By  delivering  a  32 -bit  value  and 
checking  that  the  top  12-bits  are  zero,  it  is  possible  to  detect  this  unusual, 
but  fatal  condition.  This  check  is  done  using  the  function  INVALID,  defined 
later. 

The  COMPARE  function  follows  froa  Table  5.  The  values  of  'dif'  and  'borrow' 
are  the  saae  as  delivered  by  SUB32  (although  borrow  is  expressed  slightly 
differently).  'Less'  exaaines  the  aost  significant  bit  of  the  difference  of  the 
(sign  extended)  operands  R  and  M.  This  is  the  sign  of  the  result  of  R-M,  and  it 
is  set  if  R  is  less  than  M.  Again,  this  inforaal  definition  and  its  foraal 
counterpart  are  investigated  in  Annex  B. 
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NEG:  word33  ->  nua 

|-  NEG  ■  -  ((VAL33  ■  .  0)  ->  0  |  (VAL33(NOT33  ■)  +  1) 


ADD32:  word32£word32  ->  vord32£bool£bool 
|-  ADD32  (r,a)  . 

(let  sua  -  WORD34 ( ( VAL33 ( SIGNEZT  r))  +  (VAL33(SIGNEZT  ■)))  in 
let  opposite  -  (EL  31  (BITS32  r))  ZOR  (EL  31  (BITS32  ■))  in 
TRIM34T032  sue,  (EL  32  (BITS34  sue))  ZOR  opposite, 

(EL  32  (BITS34  sue))  ZOR  (EL  31  (BITS34  sue))) 


SUB32:  vord32£vord32  ->  vord32£bool£bool 
|-  SUB32  (r,e)  « 

(let  dif  .  W0RD34((VAL33( SIGNEZT  r))  +  (NEG( SIGNEZT  e)))  in 
let  opposite  -  (EL  31  (BITS32  r))  ZOR  (EL  31  (BITS32  e))  in 
TRIN34T032  dif,  (EL  32  (BITS34  dif))  ZOR  opposite, 

(EL  32  (BITS34  dif))  ZOR  (BL  31  (BITS34  dif))) 


INCP32:  vord20  ->  word32 

|-  INCP32  p  .  VALUE (ADD32 ( PAD20T032  p,  WORD32  1)) 


COMPARE:  vord4£vord32£vord32£bool  ->  bool 
|-  COMPARE  (fsf ,r,e,b)  - 
(let  op  -  VAL4  fsf  in 

let  dif  -  WORD34((VAL33( SIGNEZT  r))  +  (NEG (SIGNEZT  b)))  in 

let  equal  ■  c  ■  a  in 

let  less  -  EL  32  (BITS34  dif)  in 

let  borrov  -  (BL  32  (BITS34  dif))  ZOR 

((EL  31  (BITS32  r))  ZOR  (EL  31(BITS32  a)))  in 
((op  -  0)  ->  less 

((op  -  1)  ->  NOT  less 

((op  «  2)  ->  equal 

((op  «  3)  ■>  NOT  equal 

((op  «  4)  ->  less  OR  equal 

((op  -  5)  ->  NOT (less  OR  equal) 

((op  -  6)  ->  borrov 

((op  -  7)  ->  NOT  borrov  | 

((op  ■  8)  ->  less  OR  b  | 

((op  -  9)  ->  (NOT  less)  OR  b  j 

((op  -  10)  ■>  equal  OR  b  j 

((op  -  11)  ->  (NOT  equal)  OR  b  j 

((op  «  12)  «>  (less  OR  equal)  OR  b  | 

((op  -  13)  ->  (NOT (less  OR  equal))  OR  b  | 

((op  ■  14)  •>  borrov  OR  b  j 

(NOT  borrov)  OR  b)))))))))))))))) 


i 
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The  next  group  of  auxiliary  functions  is  concerned  vith  the  VIPER 
architecture  itself,  rather  than  vith  Manipulation  of  words  and  rows  of 
booleana.  Proa  Table  2  it  is  clear  that  the  R  input  to  the  ALU  can  be  defined 
by  the  BOL  function  REG  given  opposite. 

Generation  of  addresses  for  writing  and  reading  is  perforaed  using  the  function 
OFFSET,  to  generate  a  32-bit  value  which  is  checked  by  the  predicate  INVALID  to 
aake  sure  that  none  of  the  top  12-bits  are  set.  If  INVALID  delivers  FALSE  it 
is  certain  that  the  value  In  question  can  be  triaaed  safely  back  to  20  bits  and 
then  used  as  a  aeaory  or  input/output  address.  The  expression:- 

INVALID(OFFSBT(as  f ,  addr ,  x ,  y  )  ) 

is  used  in  the  rest  of  the  description  for  checking  addresses  in  the  VIPER 
high-level  specification.  Mote  that  addition  of  a  positive  offset  to  a  negative 
value  in  X  or  T,  generating  a  non-negative  result,  is  perfectly  legal. 

Fetching  instructions  froa  aain  aeaory  involves  padding  the  20-bit  value  of  P 
with  a  leading  sero  and  using  the  resulting  21-bit  arguaent  in  the  function 
INSTFBTCH.  This  concatenation  is  achieved  readily  using  the  list  constructor 
CONS. 

Writing  to  and  reading  froa  the  tvo  contiguous  address  spaces  involves  the 
introduction  of  the  boolean  variable  "io" ,  which  aodels  the  one-bit  signal 
controlling  the  division  between  aain  aeaory  and  the  input/output  space.  As 
will  be  seen  froa  both  HBMREAD  and  MBHVRITE  this  is  regarded  as  an  extra  bit  to 
be  concatenated  vith  the  20-bit  address  generated  by  the  rest  of  the  aa chine, 
to  perform  accesses  to  a  21-bit  regiae.  These  functions  MBMRBAD  and  HEMVRITE 
assuae  that  the  address  generated  by  OFFSET(asf,  addr,  x,  y)  is  valid,  i.e. 
that  INVALID  delivers  FALSE.  The  validity  of  this  assuaption  is  guaranteed  by 
the  use  of  INVALID  to  trap  illegal  addresses  before  MBMREAD  and  HEMVRITE  are 
invoked  (see  NEXT).  The  generation  of  the  H  input  to  the  ALU  using  MEMREAD 
involves  one  extra  factor.  If  a  shift  instruction  is  Invoked,  (dsf  <-  5  and 
fsf  «  12),  there  is  no  read  required,  since  the  operation  is  on  the  R  input 
only.  In  these  circuastances,  vith  the  boolean  variable  "nil”  set  to  TRUE,  the 
M  input  is  defined  to  be  a  32-bit  representation  of  sero.  Also  notice  if  asf-0 
in  MBMREAD,  the  value  of  the  M  input  of  the  ALU  is  the  addr  field  of  the 
instruction  padded  to  32-bits.  In  HEMVRITE,  asf*0  is  illegal  (and  will  actually 
be  trapped  in  NEXT) ,  so  doesn't  change  the  contents  of  RAM. 
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BEG:  vord2£vord32£vord32£vord32£vord20  ->  vord32 
|-  EEG  (rsf ,a,x,y,p)  - 
(lei  r  ■  VAL2  rsf  in 

((r  -  0)  ->  a  |  «r  -  1)  ->  x  |  <(r  -  2)  «>  y  |  PAD20T032  p)») 


OFFSET:  vord2£vord20£vord32£vord32  ->  vord32 
|-  OFFSET  (asf, addr, x,y) 

(1st  af  -  VAL2  asf  in 
let  addr32  -  PAD20T032  addr  in 
((■£  -  0)  ->  addr32  | 

((■f  -  1)  ->  addr32  | 

((■f  -  2)  ->  VALUE( ADD32 (addr 32 ,  x))  | 

VALUE(AD032(addr32,  y)))))) 


INVALID:  vord32  ->  bool 

|-  INVALID  value  .  NOT (value  -  PAD20T032 (TRIM32T020  value)) 


INSTFETCH:  aea21  32£vord20  ->  vord32 
|-  INSTFETCH  (raa,pT  -  FBTCH21  raa  (V0RD21(V(C0NS  F  (BITS20  p)))) 


MEMREAD:  aem2132£vord2£vord20£vord32£vord32£bool£bool  ->  vord32 
|-  MEMREAD  (raa, asf ,addr ,x,y , io.nil)  « 

(let  a  -  VAL2  asf  in 
(  nil  ->  V0RD32  0  | 

((a  -  0)  ->  PAD20T032  addr  | 

FETCH 21  ran 

(V0RD21(V(C0NS  lo  (BITS20(TRIM32T020(0FFSET(asf ,addr,x,y)))))))))) 


MEMVRITE:  aea21_32£vord32£vord2£vord20£vord32£vord32£bool  ->  aea21_32 
|-  MEMVRITE  (raa, source, asf ,addr,x,y,io)  - 
(let  a  -  VAL2  asf  in 
((a  -  0)  ->  raa  | 

STORE 21 

(V0RD21(V(C0NS  io  (BITS20(TRIM32T020(0FFSET(asf ,addr,x,y))))))) 
source  raa)) 
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The  function  for  the  ALU  regains  to  be  declared  before  aoving  to  the 
definition  of  the  permissible  state  transitions  for  VIPER .  The  ALU  delivers  a 
triple  consisting  of  a  32-bit  result,  the  next  state  of  the  B  flag  and  a  value 
for  the  STOP  condition  flag.  As  can  be  seen  froa  the  facing  page,  the  ALU  is 
very  simple  in  concept,  the  most  obvious  feature  being  that  most  operations  are 
barred  on  the  P  register.  Only  addition  and  subtraction  vith  overflow 
protection,  CALL  instructions  and  reads  from  memory  or  manifest  constants  can 
be  used  to  define  the  new  contents  of  the  P  register.  The  definition  of  the  ALU 
follows  Table  6  in  a  natural  manner. 
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ALU:  vord4£vord2£vord3£vord32£vord32£bool  ->  vord32£bool£bool 
ALU  (faf ,aaf ,daf ,r,a,b)  « 

(let  ££  -  VAL4  £s£  in 

let  ■£  .  VAL2  asf  in 

let  d£  -  VAL3  d«f  in 

let  pvrite  -  (df  -  3)  <»  ((df  -  4)  OR  (d£  -  5))  in 

((ff  -  0)  ->  (NOT32  m,  b,  pvrite)  | 

((££  -  1)  ->  (a,  b,  (NOT  pvrite)  OR  (INVALID  ■))  | 

((££  -  2)  ->  (a,  b,  pvrite)  | 

((££  «  3)  ->  (a,  b,  pvrite  AND  (INVALID  a))  | 

((ff  -  4)  ->  let  aua  »  ADD32(rfa)  in 

VALUE  aua,  CARRY  aua,  pvrite  | 

((££  -  5)  «>  let  aua  -  ADD32(rfa)  in 

VALUE  aua,b,  (OFLO  aua)  OR  (pvrite  AND  ( INVALID( VALUE  aua)))| 
((££  -  6)  ->  let  dif  -  SUB32(rfa)  in 

VALUE  dif,  CARRY  dif,  pvrite  | 

((ff  «  7)  ->  let  dif  -  SUB32(r,a)  in 

VALUE  dif ,b,  (OFLO  dif)  OR  (pvrite  AND  <INVALID( VALUE  dif)))| 
((ff  -  8)  ->  ((r  QR32  a)  AND32  (N0T32(r  AND32  a)),  b,  pvrite)  | 

((ff  -  9)  ->  (r  AND32  a,  b,  pvrite)  | 

((ff  -  10)  ->  (NOT32(r  0R32  a),  b,  pvrite)  | 

((ff  -  11)  ->  (r  AND32  (NOT32  a),  b,  pvrite)  | 

((ff  -  12)  ->  ((af  >  0)  ->  ( RIGHT ARITH  r,  b,  pvrite)  i 

((af  -  1)  ->  (RIGBT(b,r),  EL  0  (BITS32  r),  pvrite)  | 

((af  -  2)  ->  let  double  -  ADD32(r,r)  in 

VALUB  double,  b,  (OFLO  double)  OR  pvrite  | 
(LEFT(r,b),  EL  31(BITS32  r),  pvrite))))  | 

((ff  -  13)  «>  (r,b,T)  | 

((ff  -  14)  ->  (r,b,T) 

(r,b,T) ))))))) ))))))))) 
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To  vrit«  a  concise  stateaant  of  all  peraissible  transitions  in  VIPER,  it  is 
convenient  in  the  HOL  text  to  define  a  nuaber  of  priaary  predicates  derived 
froa  the  fields  of  the  current  instruction  and  the  current  value  of  B:- 

VRITB  which  is  TRUE  if  the  instruction  involves  writing  to  the  aain  aeaory  or 
the  peripheral  space 

NILM  which  is  TRUE  if  no  M  input  is  required  to  the  ALU 

NOOP  which  is  TR,TE  if  no  operation  is  to  be  perforaed,  ie  SKIP 

SPAREFUNC  which  becoaes  TRUE  if  any  atteapt  is  aade  to  use  ALU  functions  13,  14 
or  IS 


ILLEGALCALL  which  becoaes  TRUE  if  an  illegal  CALL  instruction  is  atteapted 
(with  the  destination  defined  as  the  A,  Z  or  T  registers) 

ILLBGALPDEST  which  becoaes  TRUB  if  the  destination  is  given  as  P  but  the 

specified  function  is  an  illegal  way  of  deriving  a  new  value  of  the 
prograa  counter 

ILLBGALVRITB  vhich  is  TRUE  if  a  WRITE  instruction  is  atteapted  vith  the  aeaory 
select  field  equal  to  0 

OUTPUT  vhich  is  TRUE  if  data  is  to  be  written  to  an  address  in  the  10  space, 
ie  NOT  a  coaparlson  and  df  ■  6 

INPUT  vhich  is  TRUE  if  data  is  being  read  froa  an  address  in  the  10  space, 
ie  NOT  a  coaparlson,  df  <-5  and  ff  ■  2. 


WRITE:  vord3£vordl  ->  bool 
)-  WRITE  (dsf, csf)  - 
(lot  df  -  VAL3  dsf  in 
let  c£  -  VAL1  csf  in 
(cf  -  0)  AND  ((df  -  7)  OR  (df  -  6))) 

NILM:  vord3£vordl£vord4  ->  bool 
|-  NILE  (dsf , csf , fsf)  - 
(let  df  -  VAL3  dsf  in 
let  cf  -  VAL1  csf  in 
let  ff  -  VAL4  fsf  in 

(cf  -  0)  AND  ((N0T((df  .  7)  OR  (df  -  6»)  AND  (ff  -  12))) 

HOOP:  vord3£vordl£bool  ->  bool 
|-  NOOP  (dsf ,csf ,b)  - 
(let  df  -  VAL3  dsf  in 
let  cf  -  VAL1  csf  in 

(cf  -  0)  AND  (((df  -  5)  AND  b)  OR  ((df  -  4)  AND  (NOT  b)))) 

SPAREFUNC:  vord3£vordl£vord4  ->  bool 
|-  SPAREFUNC  (dsf , csf, fsf)  - 
(let  df  -  VAL3  dsf  in 
let  cf  »  VAL1  csf  in 
let  ff  -  VAL4  fsf  in 

(cf-O)  AND  ((N0T((df-6)  OR  (df-7)))  AND  ((ff-13)  OR  ((ff-14)  OR  (ff-15))))) 


ILLBGALCALL:  vord3£vordl£vord4  ->  bool 
|-  ILLBGALCALL  (dsf , csf, fsf)  - 
(let  df  -  VAL3  dsf  in 
let  cf  -  VAL1  csf  <n 
let  ff  -  VAL4  fsf  in 

(cf  -  0)  AND  ((ff  -  1)  AND  ((df  -  0)  OR  ((df  -  1)  OR  (df  -  2))))) 

ILLEGALPDEST :  vord3£vordl£word4  ->  bool 
|.  ILLEGALPDEST  (dsf , csf, fsf)  - 
(let  df  -  VAL3  dsf  in 
let  cf  *  VAL1  csf  in 
let  ff  -  VAL4  fsf  in 

(cf  -  0)  AND  (((df  -  3)  OR  ((df  .  4)  OR  (df  -  3)))  AND 

(NOT((ff  .  1)  OR  ((ff  -  3)  OR  ((ff  -  5)  OR  (ff  .  7))))))) 


ILLEGALWRITE:  vord3£vordl£word2  ->  bool 
|-  ILLEGALWRITE  (dsf ,csf ,asf )  - 
(let  af  -  VAL2  asf  in  (WRITB(dsf ,csf ))  AND  (af  -  0)) 

OUTPUT:  vord3£wordl  ->  bool 
|-  OUTPUT  (dsf, csf)  - 
(let  df  ■  VAL3  dsf  in 

let  cf  -  VAL1  csf  in  (cf  -  0)  AND  (df  -  6)) 

INPUT:  vord3£vordl£vord4  ->  bool 
|-  INPUT  (dsf , csf , fsf)  - 
(let  df  *  VAL3  dsf  in 
let  cf  -  VAL1  csf  in 
let  ff  -  VAL4  fsf  in 

(cf  -  0)  AND  ((NOT((df  -  7)  OR  (df  -  6)))  AND  (ff  -  2))) 


18 


VIPER  Bust  obey  the  transitions  defined  in  the  function  NEXT  on  the  opposite 
page.  Table  4  gives  the  details  of  the  nev  states  to  be  achieved.  As  can  be 
seen  froa  the  definition  of  NEXT,  precise  descriptions  of  the  conditions  in 
which  the  "io"  signal  is  TRUE  and  for  detection  of  invalid  addresses  are  found 
in  the  BOL  text  and  provide  a  rigorous  definition  of  the  looser  stateaents  in 
Section  2. 

One  issue  which  was  not  dealt  with  at  all  in  the  inforaal  description  of 
Section  2  is  the  problea  of  overflow  of  the  prograa  counter.  If  an  instruction 
has  been  fetched  froa  the  top  word  of  the  aain  aeaory,  it  follows  that  the  next 
increaent  of  the  prograa  counter  will  cause  an  illegal  value  to  be  generated 
for  P  unless  this  last  instruction  is  GOTO.  Notice  that  if  the  instruction 
fetched  froa  the  top  word  is  CALL,  difficulties  aay  be  encountered  later  in  the 
execution  of  the  prograa,  because  an  illegal  return  link  will  have  been  stored 
in  the  T  register.  In  view  of  the  coaplexity  this  could  introduce,  any 
instruction  in  the  top  word  of  aeaory  is  illegal  in  VIPER  and  if  encountered 
stops  the  processor. 

The  function  NEXT  contains  the  one  substantive  change  between  this  report 
and  Report  85013  (9).  The  expression  "AND  (NOT  skip)"  has  been  added  to  the 
definition  of  "illegaladdr”.  The  reason  for  this  is  that,  when  the  previous 
top-level  specification  (9)  was  coapared  with  the  first  level  of  decoaposition 
(the  aicroprograa  aodel  described  in  reference  5),  it  was  discovered  that  they 
differed  when  a  conditional  call  or  goto  instruction  delivered  an  illegal  nev 
value  for  the  prograa  counter.  In  the  original  description  (9),  the  illegal 
result  was  detected  before  the  B  flag  was  exaained  to  see  if  the  instruction 
was  to  be  perforaed.  This  led  to  the  processor  always  stopping.  The 
iapleaentation  (5)  exaained  the  B  flag  first  and  only  generated  the  nev  value  of 
the  prograa  counter  (and  hence  only  stopped  if  it  was  illegal)  if  the 
conditional  operation  vas  to  be  perforaed.  The  latter  aore  closely  reflected 
the  designers'  intended  response  to  these  circuastances  and  so  the  top-level 
specification  has  been  changed  to  reflect  this  nev  requireaent. 
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aea21  32£vord20£vord32£vord32£vord32£bool£bool 


|-  REST  (raa,p,a,x,y,b,stop)  - 
(let  in* tbits  -  BITS32 ( INSTFETCH ( rs* , p ) )  in 
let  nevp  .  TEIM32T020(INCP32  p)  in 

let  rsf  -  V0RD2(V(SEG  (30,31)  instbits))  in 

let  asf  m  V0RD2(V(SEG  (28,29)  instbits))  in 

let  dsf  -  W0RD3(V(SEG  (25,27)  instbits))  in 

let  csf  -  W0RD1(V(SEG  (24,24)  instbits))  in 

let  fsf  -  VQRD4(V(SEG  (20,23)  instbits))  in 

let  addr  •  V0RD20(V(SBG  (0,19)  instbits))  in 

let  df  -  VAL3  dsf  in 

let  cf  -  VAL1  csf  in 

let  ff  -  VAL4  fsf  in 

let  coap  -  cf  -  1  in 

let  call  -  (cf  -  0)  AMD  (ff  -  1)  in 

let  output  -  OUTPUT (dsf ,c*f)  in 
let  input  -  XMPUT(dsf ,caf ,fsf)  in 

let  io  ■  output  OR  input  in 

let  vriteop  -  VRITB(dsf ,csf )  in 
let  skip  -  NOOP (dsf ,csf,b)  in 

let  nolnc  -  INVALID(INCP32  p)  in 

let  illegaladdr  -  (MOT(NILM(dsf ,csf ,fsf )))  AND 

((INVALID(OFFSBT(Bsf,addr,x,y)))  AND  (NOT  skip))  in 
let  illegalcl  -  ILLBGALCALL(dsf ,csf ,fsf )  in 
let  illegalsp  «  SPARRFUNC(dsf ,csf ,fsf )  in 
let  illegalonp  -  ILLEGALPDBST(dsf ,csf ,fsf)  in 
let  lllegalvr  -  ILLEGALVRITE(dsf ,csf ,asf)  in 
let  source  -  RBG(rsf ,a,x,y,nevp)  in 

(  stop  «>  (raa,  p,  a,  x,  y,  b,  T)  | 

((noinc  OR  illegaladdr)  OR  ((illegalcl  OR  illegalsp)  OR 
(illegalonp  OR  illegalvr))  ->  (raa,  nevp,  a,  x,  y,  b,  T)  | 

(  coap  »>  (raa,  nevp,  a,  x,  y, 

COMPARE(fsf,source,HEMREAD(ran,nsf,addr,x,y,io,F),  b),  P)  | 

(  vriteop  ->  (MBMVRITB(raa, source, asf, addr, x,y,lo),  nevp,  a,  x,  y,  b,  F)  | 

(  skip  «>  (ran,  nevp,  a,  x,  y,  b,  F)  | 

let  a  -  MEMRSAD(raa, asf , addr, x,y,io,NILM(dsf , csf , fsf ))  in 

let  aluout  -  ALU(fsf, asf , dsf , source, a, b)  in 
((df  -  0)  »>  (raa,  nevp,  VALUE  aluout,  x,  y,  BVAL  aluout,  SVAL  aluout)  | 

((df  -  1)  «>  (ran,  nevp,  a,  VALUB  aluout,  y,  BVAL  aluout,  SVAL  aluout)  j 

((df  -  2)  ->  (ran,  nevp,  a,  x,  VALUB  aluout,  BVAL  aluout,  SVAL  aluout)  | 

(call  ->  (ran,  TRIM32T020(VALUE  aluout),  a,  x,  INCP32  p, 

BVAL  aluout,  SVAL  aluout)  | 

(raa,  TRIM32T020(VALUB  aluout),  a,  x,  y, 

BVAL  aluout,  SVAL  aluout))))))))))) 


4.  CONCLUSIONS 


This  document  demonstrates  that  it  is  possible  to  vrite  a  specification  for 
the  functions  of  a  powerful  microprocessor,  using  simple  concepts  in  first 
order  logic.  Experience  has  shown  that  HOL  is  a  fin  basis  for  the  formal 
specification  of  VIPER. 
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Annex  A:  Short  introduction  to  HOL 

The  material  in  this  annex  is  a  very  brief,  informal,  digest  of  that 
presented  by  Gordon  in  reference  3.  Hopefully  it  contains  enough  detail  to 
enable  the  text  of  section  3  to  be  understood. 


The  description  in  section  3  assumes  the  existence  of  the  following  types 

bool  the  boolean  type  with  members  T  and  F 

nun  the  non-negative  integers 

vord<n>  a  word  of  <n>  bits  (eg  vordl,  vord32  etc) 

*  list  a  list  of  any  other  type  (eg  bool  list),  the  empty  list  is  I] 


The  description  in  section  3  also  assumes  the  existence  of  certain  operators 
and  functions:- 


NOT 

OR 

AND 

ZOR 

CONS 


HD 

TL 

EL 

SEG 

V 


SORD<n> 

VAL<n> 

BITS<n> 


equality  between  values  *£*  ->  bool 

addition  num£num  ->  num 


logical  inversion 
disjunction 
conjunction 
exclusive  OR 


bool  ->  bool 
boolCbool  ->  bool 
booltbool  ->  bool 
boolCbool  ->  bool 


list  constructor  *  ->  *  list  ->  *  list 

This  appends  a  value  to  the  head  of  a  list.  Note  that  the  form  of  the 
signature  denotes  a  partially  applied  function  (see  3),  but  for  most 
purposes  it  can  be  regarded  as  being  *£*  list  ->  *  list. 

Note  however  that  CONS  is  applied  to  two  values  'a'  and  'b'  as 
"CONS  a  b",  whilst  a  normal  function  'C'  would  be  applied  as  "C(a,b)" 


head  of  list  *  list  ->  * 

tail  of  list  *  list  ->  *  list 

<n>th  element  of  list  num  ->  *  list  ->  * 

(0  -  first  member,  for  a  list  of  H  elements  EL  (M-l)  list  *  HD  list) 
select  a  slice  from  a  list  (numCnum)  ->  *  list  ->  *  list 


the  integer  equivalent  of  a  bool  list  (ie  a  list  vith  M  members 
delivers  a  value  in  the  range  0  to  2**M  -1)  bool  list  ->  num 

converts  an  integer  to  a  vord<n>  num  ->  vord<n> 

converts  a  vord<n>  to  an  integer  vord<n>  ->  num 

converts  a  vord<n>  to  a  bool  li-t  vord<n>  ->  bool  list 


The  main  'control'  structure  is  the  conditional  expression:- 
(a  ->  b  |  c),  which  is  read  as  "if  a  then  b  else  c". 
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Annex  B:  VIPER  arithmetic 


This  annex  describes  the  arithmetic  operations  ADD32  and  SUB32,  and 
informally  justifies  the  relationship  between  the  informal  descriptions  of 
overflow,  carry  etc.  given  on  page  11  and  their  formal  ccunterparts  on  page  12. 

Before  these  are  considered  some  basic  definitions  are  required.  VIPER'S  (or 
any  other  computer's)  integers  are  not  the  same  as  a  mathematician's  integers, 
in  that  any  computer  has  a  fixed  word  length  whilst  conceptual  integers  have  an 
infinite  range  (actually  a  double  infinite  range,  from  -infinity  to  +infinlty). 
In  this  annex,  all  'computer  words'  of  <n>  bits  will  be  regarded  as  positive 
values  in  the  range  0  to  two  to  the  power  <n>  -  1.  VIPER'S  32-bit  words  can  be 
interpreted  as  either  a  2's  complement  signed  value  or  an  unsigned  value.  If 
'pow<n>'  is  defined  to  be  2  to  the  power  <n>  (ie:  pow4  -  16  etc),  then  an 
unsigned  VIPER  32 -bit  word  V  has  the  equivalent  integer  range  I  as  foil ows:- 

For:-  0  <«  V  <  pow32  then  I  «  V 

or:-  0  <-  I  <  pov32  then  V  -  I 

A  32-bit  2's  complement  VIPER  word  V,  maps  to  an  integer  I  as : - 


For:- 

0  <« 

V 

< 

pow31 

then 

I  - 

V 

and:- 

pow31  <= 

V 

< 

pow32 

then 

I  - 

V  -  pow32 

or:- 

0  <« 

I 

< 

pow31 

then 

V  . 

I 

and:~ 

-pow31  <« 

I 

<- 

-1 

then 

V  - 

I  +  pow32 

To  avoid  confusion,  bit-<n>  of  a  word  will  be  said  to  correspond  to  the  HOL 
statement  "EL  n  ....".  This  means  that  the  least  significant  bit  is  bit-0, 
rather  than  bit-1,  but  means  that  if  a  value  is  regarded  as  the  sun  of  a  series 
of  powers  of  two,  then  bit-<n>  corresponds  to  pow<n>. 

Two  theorems  will  be  used  frequently  in  the  following  discussions.  If  V 
represents  a  VIPER  word,  such  that:-  0  V  <  pow<n>,  then  all  the  bits  that  are 
set  in  the  word  must  be  in  the  first  <n>  bits  (ie  bit-0  to  bit-<n-l>),  all  other 
bits  being  clear.  For  example,  if:-  0  <«  V  <  4  (pow2),  then  only  the  first  two 
bits  of  the  word  nay  be  set,  all  subsequent  bits  are  known  to  be  clear. 

Also  if:-  pow<n>  <«  V  <  pow<n+l>,  then  bit-<n>  of  the  word  is  set. 

For  example,  if:-  4  <«  V  <  8,  then  the  third  bit  (bit-2)  of  the  word  is  set. 

Note  that:-  pow<n>  +  pow<n>  «  pow<n+l>. 


1)  The  effect  of  SIGNEXT 

SIGNEXT:  word32  ->  word33 
|-  SIGNEXT  w  * 

(let  bitlist  -  BITS32  w  in  V0RD33(V(C0NS(EL  31  bitlist)  bitlist))) 

All  the  arithmetic  operations  work  with  'sign  extended'  words.  The  effect  of 
this  function,  in  the  realm  of  integers,  depends  upon  whether  the  value  being 
extended  is  considered  as  a  signed  or  unsigned  value. 

l.a)  Signed  values:  If  the  notional  Integer  value  is  I,  the  VIPER  word  is  V, 
and  SXV  is  the  effect  of  sign  extension  on  V. 

0  <-  I  <  pov31  then  V  -  I  and  SXV  -  I 

-pov31  <*  I  <  0  then  V  -  I  +  pow32  and  SXV  -  I  +  pow32  +  pow32 
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l.b)  Unsigned  values:  If  the  notional  integer  value  is  I,  the  VIPER  word  is  V, 
and  STV  is  the  effect  of  'sign  extension'  on  V. 

0  <-  I  <  pov31  then  V  -  I  and  SXV  .  I 

pov31  <-  I  <  pov32  then  V  -  I  and  SXV  -  I  +  pov32 


2)  The  addition  function,  ADD32 

ADD32:  vord32£vord32  ->  vord32£bool£bool 
|-  A0D32  (r,«)  . 

(let  sue  -  W0RD34 ( (VAL33 ( SIGNEXT  r))  +  ( VAL33 ( SIGNEXT  ■)))  in 

let  opposite  -  (EL  31  (BITS32  r))  XOR  (EL  31  (BITS32  ■))  in 

TRIM34T032  sua,  (EL  32  (BITS34  sue))  XOR  opposite, 

(EL  32  (BITS34  sua})  XOR  (EL  31  (BITS34  sua))) 

As  shown  above,  AD032  delivers  three  values,  the  32-bit  sua,  a  carry 
condition  and  an  overflow  condition.  The  overflow  condition  is  only  of 
interest  during  2's  coapleaent  addition,  whilst  carry  is  only  used  by  unsigned 
addition.  These  two  signals  will  therefore  be  considered  separately. 

2.1)  Overflow  during  addition 

If  II  and  12  are  tvo  32-bit  signed  integer  values  to  be  added,  then  the 
natural  definition  of  overflow  is  any  result  of  11+12  that  cannot  be  represented 
as  a  32-bit  value.  That  is:- 

overflov  -  ((11+12)  <  -pow31)  OR  ((11+12)  >-  pov31) 

Unfortunately,  when  the  VIPER  specification  was  vritten,  HOL  did  not  support 
negative  integers,  so  an  alternative  description  in  the  regine  of  positive 
values  was  required.  If  II  and  12  are  represented  by  the  two  32-bit  2's 
conplenent  words  R  and  M  (as  defined  above),  the  definition  of  overflov  given 
in  the  ADD32  function  is  such  that  an  overflov  is  said  to  have  occurred  if 
bit-31  and  bit-32  of  the  result  of  adding  the  tvo  sign  extended  words  together 
are  different.  This  statenent  is  to  be  justified  in  the  next  three  sections. 

Also  it  should  be  noted  that  the  32-bit  value  delivered  from  ADD32  is  neant 
to  be  equal  to  the  2's  conplenent  sun  of  II  and  12  in  the  absence  of  overflov. 

If  an  overflov  has  occurred  this  value  has  no  significance. 

2.1. a)  Addition  overflov  when  II  and  12  both  positive 

Here  R  -  II,  and  M  -  12,  and  the  sign  extension  process  doesn't  change 
these  values.  So  the  sua  of  the  sign  extended  words  is:-  SUM  >11+12. 

Note  that:-  0  <>  II  +  12  <-  pov31  +  pov31  -  2 

There  are  tvo  regions  in  the  result  space,  if  (11+12)  <  pov31,  then  no 
overflov  has  occurred,  and  SUM  is  also  less  than  pov31,  so  bit-31  and  bit-32  of 
the  result  are  both  clear.  So  no  overflov  and  bit-31  and  bit-32  of  SUM  are 
the  sane  also  the  32-bit  result  delivered  -  SUM. 

An  overflov  can  only  occur  if  (11+12)  >-  pov31.  This  corresponds  to  SUM  also 
being  greater  than  pov31.  Hovever  the  aaxiaua  value  of  (11+12)  is 
pov31-l  +  pov31-l  -  pov32-2.  So  if  an  overflov  has  occurred : - 

pov31  <-  SUM  <  pov32-l 

This  naans  that  bit-31  is  set  but  bit-32  is  clear.  So  bit-31  and  bit-32  of 
SUM  are  different  when  an  'overflow'  has  occurred. 
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2.1.b)  Addition  overflov  vhen  II  and  12  both  negative 

Sere  R  -  II  +  pov32,  and  M  -  12  +  pov32.  The  sign  extension  process  adds 
a  further  pov32  to  both  these  values.  The  sua  of  the  sign  extended  vords  is 
therefore:-  SUM  -  II  +  12  +  pov32  +  pov32  +  pov32  +  pov32. 

Note  that:-  -pov32  <-  II  +  12  <-  -2 

There  are  tvo  regions  in  the  result  space,  if  -pov31  <-  (11+12)  <-  -2,  then  no 
overflov  has  occurred,  and  SIM  is:- 

SUM  -  pov33  +  pov32  +  (pov32  +  II  +  12) 

Where  (pov32  +  II  ♦  12)  is  in  the  range  pov31  to  pov32-2,  that  is  the  32nd  bit 
of  the  result  is  set,  and  as  pov32  occurs  in  the  definition  of  SUM,  the  33rd  is 
also  set.  So  no  overflov  and  the  32nd  and  33rd  bits  of  SUM  are  the  sane. 

Triaaing  SUM  to  32-bits  effectively  subtracts  pov33  and  pov32  froa  SUM,  so  the 
32-bit  result  delivered  is  (pov32  1  +  12),  vhich  is  the  2's  coapleaent 
equivalent  of  the  result. 

An  overflov  can  only  occur  if  -pov32  <-  (11+12)  <  -pov31,  but  SUM  is:- 
SUM  m  pov33  +  pov32  +  (pov32  +  II  +  12) 

Where  (pov32  +  II  +  12)  is  in  the  range  0  to  pov31-l,  that  is  bit-31  of  the 
result  is  clear,  and  as  pov32  occurs  in  the  definition  of  SUM,  blt-32  is  set. 

So  bit-31  and  bit-32  of  SUM  are  different  and  an  'overflov'  has  occurred. 


2.1.c)  Addition  overflov  vhen  the  signs  of  the  operands  are  different 

Under  these  circunstances  the  result  of  the  addition  can  never  overflov,  as 
the  range  of  the  result  is:- 

-pov31  <-  11+12  <  pov31-l 

The  sign  extension  process  adds  a  further  pov32  to  one  value,  so  the  sua  of 
the  sign  extended  vords  is  therefore:-  SUM  -  II  +  12  +  pov32  +  pov32. 

If  11+12  is  positive,  its  aaxlaua  value  is  pov31-2,  so  bit-31  and  bit-32  of 
SUM  are  both  clear.  So  bit-31  and  bit-32  of  SUM  are  the  saae  and  no  overflov 
has  occurred.  Also  triaaing  the  result  to  32-bits  vill  deliver  II  +  12. 

If  11+12  is  negative,  it  is  in  the  range  -pov31  to  -1,  so  SUM  is:-  SUM  « 
pov32  +  pov31  +  (pov31  +  II  +  12),  vbere  (pov31  +  II  +  12)  is  in  the  range  0  to 
pov31-l.  This  doesn't  effect  bit-31  and  bit-32  of  SUM  vhich  are  both  set.  So 
bit-31  and  bit-32  of  SIM  are  the  sane  and  no  overflov  has  occurred.  Triaaing  to 
32-bits  vill  subtract  the  pov32  tera,  so  the  result  is  pov31+pov31+Il+l2,  or 
pov32+Il+I2,  the  2's  coapleaent  fora  of  the  result. 


So  under  all  circunstances  it  has  been  (inforaally)  shown  that  if  an 
overflov  has  occurred  bit-31  and  bit-32  of  the  sign  extended  sun  differ,  but  if 
the  result  is  legal  they  are  the  saae.  Also  if  no  overflov  has  occurred  the 
result  of  the  addition  is  the  2's  coapleaent  fora  of  the  sua  11+12. 
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2.2)  Carry  during  unsigned  addition:- 


There  is  a  natural  definition  of  carry  that  could  b«  used  in  HOL.  That 
is:-  CARRY  .  (11+12)  >-  pov32 

vhere:-  0  <-  II  <  pov32,  and  0  <-  12  <  pov32 

Perversely,  the  VIPER  specification  doesn't  use  this  definition,  but  as 
the  proofs  (5,6)  were  performed  against  a  aore  coaplex  definition,  this  vill  be 
justified  here.  The  definition  of  carry  in  ADD32  is  such  that  if  the  aost 
significant  bits  of  the  operands  are  the  sane,  then  carry  is  the  bit-32  of  the 
'sign  extended'  sun,  otherwise  it  is  the  inverse  of  this  bit.  As  in  the  case  of 
overflow,  the  justification  vill  be  given  in  three  parts. 

It  should  be  noted  that  the  32-bit  result  of  ADD32  for  unsigned  addition 
is  always  (11+12)  aodulo  pov32. 


2. 2. a)  Addition  carry  when  both  operands  are  less  than  pov31 

If  II  and  12  are  the  operands,  SUN  >11+12,  vhere  0  <>  11+12  <  pov32-l. 
So  no  carry  can  ever  occur,  and  bit-32  of  SUM  is  alvays  clear. 

The  aost  significant  bits  of  the  operands  are  the  saae  and  carry  is  the 
saae  as  bit-32  of  SUM. 


2.2.b)  Addition  carry  vhen  both  operands  are  >«  pov31 

SUM  >  II  +  12  +  pov32  +  pov32  >  II  +  12  +  pov33 
vhere:-  pov32  <>  11+12  <  pov33-l. 

So  there  is  alvays  a  carry,  and  the  bit-32  of  SUM  is  alvays  set. 

The  aost  significant  bits  of  the  operands  are  the  sane  and  carry  is  the 
saae  as  bit-32  of  SUM. 


2.2.c)  Addition  carry  vhen  one  operand  <  pov31  and  the  other  >«  pov31 
SUM  .  II  +  12  +  pov32 

vhere: -  pov31  <>  11+12  <  pov32  +  pov31  -  1 

When  pov31  <>  11+12  <  pov32,  there  is  no  carry,  the  11+12  tera  doesn't 
affect  bit-32  of  SUM,  but  the  pov32  tera  aeans  that  this  bit  is  set. 

Vhen  pov32  <>  11+12  <  pov32  +  pov31  -1,  there  is  a  carry. 

SUM  can  be  rewritten  as:-  SUM  >  pov32  +  pov32  +  (II  +  12  -  pov32)  or 

>  pov33  +  (II  +  12  -  pov32). 

The  range  of  (II  +  12  -  pov32)  is  0  to  pov31-l,  so  doesn't  affect  the 
bit-32  of  SUM,  which  is  therefore  clear. 

Bence  vhen  the  aost  significant  bits  of  the  operands  are  different,  bit-32  of 
SUM  is  the  inverse  of  carry. 
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3)  The  subtraction  operator  SUB32 


NBG:  vord33  ->  nua 

|-  HBG  a  -  ((VAL33  a  -  0)  ->  0  |  (VAL33(NOT33  a)  ♦  1) 


SUB32:  vord32£vord32  ->  vord32£bool£bool 
|-  SUB32  (r,a)  - 

(let  dif  -  V0RD34((VAL33(SIGNBZT  r))  ♦  (NBG(SIGNEZT  a)))  in 

let  opposite  -  (EL  31  (BITS32  r))  ZOR  (BL  31  (BITS32  a))  in 
TR1H34T032  dif,  (EL  32  (BITS34  dif))  ZOR  opposite, 

(BL  32  (BITS 34  dif))  ZOR  (BL  31  (BITS34  dif))) 


As  can  be  seen  the  subtraction  operator  is  very  siailar  to  ADD32,  but  vith 
NBG  used  to  invert  one  of  the  operands.  The  effect  of  NBG  is:- 


For  unsigned  values : - 

I  -  0, 

0  <  I  <  pov31, 
pov31  <-  I  <  pov32, 


NBG(SIGNBZT(V)) 
NEG(SIO»BXT(W)) 
NBG(SIGNEZT(V) ) 


0 

pov33  -  I 

pov33  -  (I  ♦  pov32)  -  pov32  -I 


For  signed  values :- 
-pov31  <-  I  <-  -1, 

I  -  0, 

0  <  I  <  pov31, 


KBG(SIGNBZT(V) ) 
NBG(SIGNBZT(V)) 
NBG(SIGNEZT(V) ) 


pov33  -  (I  +  pov32  ♦  pov32)  -  -I 
0 

pov33  -  I 


Vhere  V  is  I 


aapped  onto  a  VIPER  32-bit  word  as 


discussed  above. 


3.1)  Overflov  during  subtraction 

If  II  and  12  are  tvo  32-bit  signed  integer  values  to  be  subtracted,  then  the 
natural  definition  of  overflov  is  any  result  of  11-12  that  cannot  be  represented 
as  a  32-bit  value.  That  ls:- 

overflov  -  ((11-12)  <  -pov31)  OR  ((11-12)  >-  pov31) 

The  definition  of  overflov  given  in  the  SUB32  function  is  such  that  an  overflov 
is  said  to  have  occurred  if  bit-31  and  bit-32  of  the  result  of  adding  the 
sign  extended  and  negated  vords  together  are  different.  This  stateaent  is  to  be 
justified  in  the  next  four  sections. 

The  32-bit  value  delivered  froa  SUB32  is  aeant  to  be  equal  to  the 
2's  coapleaent  representation  of  11-12  in  the  absence  of  overflov.  If  an 
overflov  has  occurred  this  value  has  no  significance. 

It  should  also  be  noted  that  in  the  COMPARE  function,  bit-32  of  DIF  is 
used  as  the  LBSS  than  condition  (ie  II  <12,  or  11-12  <  0).  This  vill  also  be 
justified. 

3.1. a)  Subtraction  overflov  vhen  II  is  positive  and  12  negative  or  zero 

DIF  -  II  +  (-  12) 

Mote  that:-  0  <-  II  -  12  <  pov3? 

There  are  tvo  regions  in  the  result  space.  If  (11-12)  <  pov31,  then  no 
overflov  has  occurred,  and  DIF  is  also  less  than  pov31,  so  bit-31  and  bit-32  of 
the  result  are  both  clear.  So  bit-31  and  bit-32  of  DIF  are  the  sane  and  no 
overflov  has  occurred,  and  the  32-bit  result  delivered  -  DIF. 
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An  overflow  can  only  occur  if  (11-12)  >-  pov31.  This  corresponds  to  DIP  also 
being  greater  than  pov31.  However  the  aaxiaiia  value  of  (11-12)  is 
pov31-l  -  (-pov31)  «  pov32-l.  So  if  an  overflow  has  occurred:- 

pow31  <•  DIF  <  pow32 

This  eeans  that  bit-31  is  set  but  bit-32  is  clear.  So  bit-31  and  bit-32  of 
DIP  are  different  and  an  overflow  has  occurred. 

Note  that  in  both  cases,  LESS  is  always  false  and  bit-32  of  DIP  is  clear. 


3.1.b)  Subtraction  overflow  when  II  is  negative  and  12  is  greater  than  zero 
DIP  -  (II  4  pov32  4  pow32)  4  (pow33  -  12) 

Note  that:-  -(pow32-l)  <»  II  -  12  <-  -2 

There  are  two  regions  in  the  result  space.  If  -pow31  <«  (11-12)  <-  -2,  then  no 
overflow  has  occurred,  and  DIP  is:- 

DIP  -  pow33  4  pow32  4  (pow32  4  II  -  12) 

Where  (pow32  4  II  -  12)  is  in  the  range  pow31  to  pow32-2,  that  Is  bit-31  of  the 

result  is  set,  and  as  pow32  occurs  in  the  definition  of  DIP,  bit-32  is  also 
set.  So  bit-31  and  bit-32  of  DIP  are  the  saae  and  no  overflow  has  occurred. 
Trining  DIP  to  32-bits  effectively  subtracts  pow33  and  pow32  froa  DIF,  so  the 
32-bit  result  delivered  is  (pov32  4  II  -  12),  which  is  the  2's  coapleaent 
equivalent  of  the  result. 

An  overflow  can  only  occur  if  -(pow32-l)  <«  (11-12)  <  -pow31,  but  DIP  is:- 

DIP  -  pow33  4  pow32  4  (pov32  4  II  -  12) 
where  (pov32  4  II  -  12)  is  in  the  range  1  to  pow31-l,  that  is  bit-31  of  the 

result  is  clear,  and  as  pow32  occurs  in  the  definition  of  DIP,  bit-32  is  set. 

So  bit-31  and  bit-32  of  DIF  are  different  and  an  overflow  has  occurred. 

Note  that  in  both  cases  LESS  is  true,  and  bit-32  of  DIF  is  set. 


3.1.c)  Subtraction  overflow  when  II  is  negative  and  12  is  negative  or  zero 

Under  these  circuastances  the  result  of  the  subtraction  can  never  overflov, 
as  the  range  of  the  result  is:- 
-pov31  <-  11-12  <  pov31 

DIP  -  (II  4  pov32  4  pov32)  4  (-12)  .  pow33  4  II  -  12 

If  11-12  is  positive,  its  aaxiaua  value  is  pov31-l,  so  bit-31  and  bit-32  of 
DIP  are  both  clear.  So  bit-31  and  bit-32  of  DIP  are  the  saae  and  no  overflov 
has  occurred.  Triaaing  the  result  to  32-bits  will  deliver  II  -  12.  LESS  is 
false  and  bit-32  of  DIP  is  clear. 

If  11-12  is  negative,  it  is  in  the  range  -pov31  to  -1,  so  DIF  is:-  DIF  - 
pov32  4  pov31  4  (pov31  4  II  -  12),  vhere  (pov31  4  II  -  12)  is  in  the  range  0  to 
pov31-l.  This  doesn't  affect  bit-31  and  bit-32  of  DIF  which  are  both  set.  So 
bit-31  and  bit-32  of  DIP  are  the  saae  and  no  overflov  has  occurred.  Triaaing  to 
32-bits  will  subtract  the  pov32  tera,  so  the  result  is  pov3l4pov3l4ll-I2,  or 
pov324ll-I2,  the  2's  coapleaent  fora  of  the  result.  LESS  is  true  and  bit-32  of 
DIP  is  set. 
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3.1.d)  Subtraction  overflow  when  II  is  positive  and  12  is  greater  than  zero 

Under  these  circumstances  the  result  of  the  subtraction  can  never  overflov, 
as  the  range  of  the  result  is:- 

-<pov31-l)  <-  11-12  <  pov31-l 

DIP  -  II  +  (pov33  -  12)  -  pov33  +11-12 

The  arguaents  used  in  3.1.C  then  follov. 


So  under  all  circuastances  it  has  been  (informally)  shown  that  if  an 
overflow  has  occurred  bit-31  and  bit-32  of  the  sign  extended  difference  differ, 
but  if  the  result  is  legal  they  are  the  same.  Also  if  no  overflow  has  occurred 
the  result  of  the  subtraction  is  the  2's  complement  form  of  the  sum  11-12,  and 
bit-32  of  DIF  corresponds  to  the  value  LESS. 


3.2)  Borrow  during  unsigned  subtraction:- 

The  natural  definition  of  borrow  (the  subtraction's  analogy  to  addition's 
carry)  iss-  BORROW  .  (11-12)  <  0 

where:-  0  <->  II  <  pow32,  and  0  <-  12  <  pow32 

The  definition  of  borrow  in  SUB32  is  such  that  if  the  most  significant  bits 
of  the  operands  are  the  same,  then  borrow  is  bit-32  of  the  'sign  extended' 
difference,  otherwise  it  is  the  inverse  of  this  bit. 

It  should  be  noted  that  the  32-bit  result  of  SUB32  for  unsigned  subtraction 
is  alvays  (11-12)  modulo  pov32. 


3. 2. a)  Subtraction  borrow  when  II  <  pow31  and  12  -  0 
DIF  .  II,  where  0  <-  11-12  <  pov31 

So  no  borrow  can  ever  occur,  and  bit-32  of  DIF  is  always  clear. 

The  most  significant  bits  of  the  operands  are  the  same  and  borrow  is 
the  same  as  bit-32  of  DIF. 


3.2. b)  Subtraction  borrow  when  II  >-  pow31  and  12-0 
DIF  -  II  +  pow32,  where  pow31  <-  11-12  <  pow32 

or:-  DIF  -  pow32  ♦  pow31  +  (II  -  12  -  pow31),  where  0  <-  Il-I2-pov31  <  pow31 

So  no  borrow  can  ever  occur,  and  bit-32  of  DIF  is  alvays  set. 

The  most  significant  bits  of  the  operands  are  different  and  borrow  is 
the  inverse  of  bit-32  of  DIF. 
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3.2.c)  Subtraction  borrov  vben  II  <  pov31  and  12  >-  pov31 

DIP  -  II  +  (pov32  -  12) 
where:-  -(pov32-l)  <-  11-12  <-  -1 
and:-  1  <-  DIF  <  pov32 

So  tharc  is  always  a  borrow,  but  bit-32  of  DIF  is  always  clear. 

The  aost  significant  bits  of  the  operands  are  different  and  borrow  is 
the  inverse  of  bit-32  of  DIF. 


3.2.d)  Subtraction  borrow  when  II  >-  pow31  and  1  <-  12  <  pow31 

DIF  -  (II  ♦  pow32)  +  (pow33  -  12)  >  pow33  ♦  pow32  ♦  (11-12) 
where:-  1  <-  11-12  <-  pow32-2 

So  there  is  never  a  borrov,  and  bit-32  of  DIF  is  always  set. 

The  aost  significant  bits  of  the  operands  are  different  and  borrov  is 
the  inverse  of  bit-32  of  DIF. 


3.2.e)  Subtraction  borrov  vhen  II  <  pov31  and  1  <«  12  <  pov31 

DIF  -  II  +  (pov33  -  12),  where:-  -<pov31-l)  <-  11-12  <-  pov31-2 

vhen: - (pov31-l)  <»  11-12  <-  -1,  there  has  been  a  borrov  and 

DIF  -  pov32  +  pov31  ♦  (pov31  ♦  II  -  12) 

The  range  of  (pov31  +  II  -  12)  is  0  to  pov31-l,  so  it  cannot  affect 
bit-32  of  DIF,  which  can  be  seen  to  be  set. 

vhen:-  0  <«  11-12  <•  pov31-2,  there  has  not  been  a  borrov  and 
DIP  -  pov33  +  (II  -  12) 

The  range  of  (II  -  12)  is  0  to  pov31~2,  so  it  cannot  affect  bit-32 
of  DIF,  vhich  can  be  seen  to  be  clear. 

The  aost  significant  bits  of  the  operands  are  the  sane  and  borrov  is 
the  saae  as  bit-32  of  DIF. 


3.2.f)  Subtraction  borrov  vhen  II  >•  pov31  and  12  >-  pov31 

DIF  -  (II  +  pov32)  ♦  (pov33  -  (12  +  pow32))  -  pow33  +11-12 
where:-  -(pov31-l)  <-  11-12  <-  pov31-l 

The  arguaents  used  in  3.2.e  still  apply  (noting  that  pov31-2  is  replaced  by 
pov31-l,  vhich  doesn't  change  any  of  the  subsequent  reasoning) 
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